주소창에 url을 입력했을 때 일어나는 과정

#web #protocol/dns #network #nginx

주소창에 url을 입력했을 때 일어나는 과정

기본 답변

주소창에 url을 입력하면 실제로 요청을 날릴 정확한 주소를 알아내는 작업이 일어납니다. IP 주소를 입력했다면 해당 IP 주소로 바로 요청이 날아가고, 도메인 네임을 입력했을 경우 먼저 캐싱된 도메인인지 확인하여 IP 주소를 찾아내고자 합니다. 캐싱이 안 됐다면 도메인 서버에 질의를 날려 IP 주소를 받아옵니다.
정확한 주소를 알게 됐다면 해당 주소로 HTTP 겟 요청을 날려 html 파일을 받아오고, 추가적인 정적 리소스 파일을 요청을 날려 받아옵니다. 이를 토대로 브라우저는 사용자에게 보기 좋게 렌더링하여 출력합니다. 이때 비동기 통신을 통해 추가적으로 데이터를 받아오는 과정이 수반되기도 합니다. 이 경우 흔히 백엔드라고 부르는 WAS 서버에서 데이터를 받아 추가적으로 화면을 구성합니다.

꼬리 질문

DNS에서 일어나는 과정을 아는가

DNS는 도메인 네임 서버라는 뜻으로 IP 주소를 사람이 보기 쉬운 이름으로 바꾸는 프로토콜을 말합니다. 이로부터 얻는 장점은 사람이 보기 쉽다는 것과, 변동 가능성이 있는 IP 주소와 다르게 고정된 주소를 사용자에게 전달할 수 있다는 것입니다.
도메인 네임 서버는 분산된 서버 구조를 가지고 있으며 전세계의 10개 가량의 루트 네임 서버와 그로부터 하위 네임을 가지는 서버들, 그 하위 네임을 가지는 서버들이 계층적으로 분산되어 있습니다. 도메인 이름을 통해 IP 주소를 알게 되는 원리는 다음과 같습니다.
먼저 루트 서버에 전체 네임을 질의합니다. 그러면 루트 서버는 해당 URL을 읽고 이를 해결할 수 있는 하위 네임 서버의 주소를 알려줍니다. 이 과정은 해당 네임 서버에서도 마찬가지로 일어나며, 가령 구글의 주소를 질의한다고 하면 전체 주소의 뒷부분부터 시작하여 차츰 타겟의 주소를 알려주는 방식입니다.
그러나 이러한 과정은 많은 트래픽을 유발하기에 대다수의 경우 DNS 정보는 캐싱됩니다. 캐싱은 브라우저, 호스트파일, 라우터, ISP의 영역에서 진행되며, 실제 DNS 질의는 루트 서버로 가기 전 위의 영역을 거치기 전에 대부분 캐싱된 정보를 바탕으로 접속할 수 있게 됩니다.

hostfile, os DNS , 브라우저 DNS 캐시, 공격 방법

DNS 캐시 참조는 브라우저, 호스트파일, OS DNS, 이후 DNS 서버로 이어집니다. 호스트파일은 사용자가 직접 파일을 수정하여 사용할 수 있으며 OS DNS는 메모리 상에서 관리되고 TTL를 가지고 있어 일정 시간이 지나면 삭제됩니다.
DNS를 활용한 해킹 방법에는 Pharming이 있습니다. DNS를 통해 해커가 악성 웹사이트 IP 주소로 사용자를 유도하는 기술입니다. 이는 DNS 서버와 캐시를 조작하는 스푸핑, 로컬의 호스트파일을 직접적으로 수정하는 방식 등으로 이뤄집니다.
호스트파일을 수정하는 방식은 이미 해커가 사용자의 로컬 PC 디스크에 접근할 권한을 얻게된 심각한 사안으로 사용자가 기민하게 대처해야 합니다. 그러나 DNS 서버에 대한 조작이 일어나는 경우, 사용자가 직접적으로 대처를 하는 것은 어려울 수 있으며 대신 ISP의 서버 대신 구글 DNS와 같은 신뢰할 수 있는 DNS 서버를 사용하거나 전자서명 기술을 도입한 DNSSEC 서버를 사용하는 등의 예방책을 세울 수 있습니다.
만약 DNS 리졸버에 수정이 가해진 상황이라면 단순하게 존재하지 않는 주소로 ping을 날려보내어 리졸빙이 일어나는지 확인하는 방식으로 확인하는 방법도 존재합니다.

DNS 서버는 3계층인가? 각 차이는 어떤가

통상적으로 DNS 서버는 루트와 TLD, authoritative 서버 구조를 가집니다. 그리고 각 서버들은 여러 개로 분산되어 있습니다. 도메인 네임에서 이 서버들은 .을 통해 구분되며 가장 뒤가 루트 서버를 나타냅니다. 흔히 보게 되는 com, kr, org 등은 상위 네임서버로 TLD라는 이름으로 불립니다. 이후 각 웹 서버의 실질적으로 연결되는 authoritative 서버가 위치합니다. 그러나 3계층으로 끝나지 않고 추가적인 하위 계층이 존재하는 것도 가능합니다.

IP주소를 알고 tcp 요청이 실제로 체결되기 이전에 네트워크에서 일어나느 과정

게이트웨이 패킷 전송.
arp, nat, 라우터

아파치와 느징스 차이

페이지는 어떻게 렌더링되는가

렌더링은 정적 리소스를 통해 진행됩니다. 기본적으로 HTML, CSS를 파싱하여 렌더 트리를 만들고, JS 해석기를 통해 JS 스크립트를 적용하여 렌더트리를 보충합니다. 단일 html 파일이 브라우저에 도착한 이후 렌더링 엔진은 해당 파일을 파싱하여 DOM 트리를 구축합니다. 이때 추가적인 요청이 필요한 link 태그가 존재할 때 다시 웹 서버로부터 비동기 요청을 보냅니다. CSS 파일이 도착하면 이것 역시 파싱하여 렌더링 엔진은 CSSOM 트리를 구축하고, 이 두 트리를 종합하여 렌더 트리를 만듭니다. JS 적용이 이뤄지는 script 태그를 만나면 동기적으로 JS 해석기가 동작하여 JS 코드를 실행하고 적용합니다. 이후에 출력할 구조와 모양을 구체화하고, 실제 화면에 출력하게 됩니다.

예시 설명(개념 불명확)

어떻게 예시를 들어야 할지 잘 모르겠당..

url과 uri의 차이는

URL은 Uniform Resource Locator의 약자로 네트워크 상의 리소스 주소를 말합니다. URI는 Uniform Resource Identifier로 인터넷에서 자원을 나타내는 식별자입니다. URI는 상위 집합에 해당하며, scheme(프로토콜), 사용자 정보, 호스트와 경로, 쿼리 등의 모든 정보를 담고 있습니다.
사용자가 사용할 때는 흔히 URL을 통해 요청을 보내게 되며, 이는 사용자 정보를 명시하지 않습니다.

HTTPS가 붙는 경우는 언제인가

HTTPS는 보안 기능이 추가된 프로토콜로 TLS 인증을 거쳐서 요청이 송수신되는 서버임을 보장합니다. 네트워크 상에서 돌아다니는 패킷은 쉽게 탈취가 가능하여 보안 정보가 탈취당할 우려가 있지만 HTTPS 프로토콜을 통한 요청은 패킷의 내용이 암호화되기 때문에 중간자의 스니핑으로부터 안전합니다. 신뢰되는 CA의 인증서를 받은 서버에 클라이언트는 공개키 알고리즘을 통해 정보를 암호화하게 되는데, 중간자가 송수신의 매개 역할을 하는 중간자 공격으로부터 안전할 수 있습니다. 이는 공개키 알고리즘을 통해 디지털 서명을 하여 신뢰되는 기관에 의해 인증받았다는 것을 입증할 수 있기 때문입니다.

HTTPS는 웹 서버 상에서 HTTP에서 리다이렉트를 반환하는 것으로 성립합니다. 이것은 전통적인 방법이고 저 역시 이러한 방법으로 웹 서버를 구축했지만 사실 이는 같은 네트워크 상의 악의적인 사용자가 초기 HTTP 요청의 정보를 뜯어볼 수 있다는 단점이 존재하기에 이를 해결하기 위해 HSTS가 적용된 브라우저에서 알아서 HTTPS 연결을 강제하기도 합니다. 이는 브라우저가 Strict-Transport-Security라는 헤더를 받는 방식으로 동작하며, 한번 HTTPS가 연결된 웹 서버에 대해 브라우저는 일정 주기 동안 알아서 모든 요청을 HTTPS를 통해 거치도록 설정합니다.

HTTP 프로토콜은 어떤 하위 프로토콜을 통해 이뤄지나

HTTP 프로토콜의 하위에서는 TCP 프로토콜이 진행되며 이는 전송 계층에서 발생합니다. TCP는 연결을 지향하는 프로토콜로, 모든 데이터가 순서대로 완전히 전송되는 것을 보장합니다. 이를 위해 TCP는 3 웨이 핸드쉐이크 과정을 통해 논리회선을 연결합니다.
3웨이 핸드쉐이크는 클라이언트가 SYN 신호를 보내고, 서버는 해당 신호에 대한 ACK를, 그리고 다시 클라이언트가 이에 대한 ACK를 송신하는 것으로 체결됩니다. 이 동안 에러와 흐름, 혼잡을 제어할 방법과 양식이 설정됩니다.

TCP 외에 아는 통신 프로토콜에 대해 말씀해주세요.

TCP 이외의 전송 계층의 프로토콜은 UDP가 대표적입니다. UDP는 연결 지향적이지 않으며 빠르게 데이터를 보내는 것에 초점이 맞춰져 있습니다. 그래서 영상과 같은 다량의 데이터가 실시간으로 전송돼야만 하는 경우에 적합합니다.

WAS 서버가 필요한 이유

페이지가 렌더링되기 위해서는 많은 데이터가 필요하며 이는 싱글 스레드를 통해 진행되기에 통상 많은 시간이 소요됩니다. 이를 해결하기 위해 페이지가 렌더링된 이후 내부를 채우는 데이터만 따로 요청을 보내 채우는 것이 가능합니다. 이 과정은 비동기로 이뤄지며 이를 통해 페이지가 새로고침되지 않더라도 실시간으로 페이지가 변동되는 것이 가능합니다.
WAS 서버를 통해 비동기적으로 데이터를 전달받는 데에는 추가적인 이유가 있습니다. WAS 서버를 사용하면 비즈니스 로직이 사용자에게 노출되는 것을 막을 수 있고, 디비 부하 분산, 최적화의 작업을 진행할 수 있습니다.

상세 정리

참고 정리